Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000021_owner-urn-ietf _Tue Mar 11 14:57:48 1997.msg

Internet Message Format | 1997-04-01 | 6KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA13627
    for urn-ietf-out; Tue, 11 Mar 1997 14:57:48 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA13622
    for <[e-mail]>; Tue, 11 Mar 1997 14:57:43 -0500 (EST)
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA15945  (mail destined for [e-mail]); Tue, 11 Mar 97 14:57:39 -0500
Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id OAA01794; Tue, 11 Mar 1997 14:57:36 -0500
Message-Id: <[e-mail]>
From: [e-mail] (Leslie Daigle)
Date: Tue, 11 Mar 1997 14:57:36 -0500
In-Reply-To: Bob Briscoe's message as of Mar 11, 14:59
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Bob Briscoe <[e-mail]>, [e-mail]
Subject: Re: [URN] URNs grandfathering certain Object or Interface References
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (Leslie Daigle)
Errors-To: [e-mail]

Bob,

I'm glad you've brought up a couple of emerging electronic namespaces that
are clear candidates for URN namespaces.

Ron may want to take a more detailed shot at NAPTR and the specific issues
you've raised wrt the use of text-replacement only for these namespaces.

I'd like to put a little context around the whole issue:

    . As Ron is very good about reminding us regularly, NAPTR is
      meant to be an _experimental_ implementation of the general
      architecture for URN systems.  It is proposed as experimental
      specifically so that we can answer questions with concrete
      experience on:

        . what are the real security issues

        .(most relevant here) what _is_ a sufficiently powerful
         and yet generally-implementable method for specifying
         transformations? (regexps are already dangerously
         complex, and yet there are clearly things they cannot do).

> The problem is that some COM/CORBA based systems can interpret these
> strings of hex digits to extract the machine/port etc. which hosts the
> object they need for resolution, but the algorithm isn't a simple textual
> transformation.
>
> How might NAPTR cope with this without just resorting to a replacement
> string and lumping the whole problem on one global resolver for the whole
> scheme leading to a horrible bottleneck?

The key thing to remember with the proposed URN resolution _framework_
is that the first step in resolution is to determine the authority
that _can_  assert machine, port, protocol for a particular URN.  I.e.,
this is step one in distributing the problem.  Step two is to perform
some kind of lookup at/of that authority to get that information.  The NAPTR
proposal uses the same basic DNS lookup algorithms for both of these steps, so
they start to look the same.  BUT, the key thing in finding a mapping from
UUIDs and IORs would be to determine how to find the authority for a particular
one, and then run some kind of local process there  to interpret the namespace-
specific stuff (HEX code, here).

So, bringing either of these namespaces into URN-land may not just be a question
of throwing "URN:IOR:" or "URN:UUID:" at the beginning of the strings.  It
may be the case that the process of developing these as URN namespaces will
include attaching some reference to the authority that will be responsible
for performing the analysis of the HEX representation.

For example,

> clsid:EFF6744C-7143-11cf-A51B-080036F12502

could become

  URN:clsid:<naming authority ID>:EFF6744C-7143-11cf-A51B-080036F12502

or even

  URN:clsid:EFF6744C-7143-11cf-A51B-080036F12502:<naming authority ID>

The first step in resolving this URN is to identify that it is a clsid
namespace URN -- this indicates how to go about finding the naming
authority ID, which can be textually extracted from either of the above.

Now, if that NA-ID can be mapped onto a machine name in some regular way
(forget the pros and cons for a moment) then even NAPTR can be used to
look up the alias, find the current address, port and protocol to speak
to it to _resolve_ the clsid-specific string (the HEX resolution process).

If you don't want to include such a NA-ID in the URN representation of the
clsid, you _could_ set up NAPTR to route _all_ clsid URNs to one global
service (which could be mirrored). Note that the global service doesn't have
to do the entire document resolution - it "only" has to apply the "hex
decoding" algorithm to the URN.  If that can't be done quickly, then it
would be a bottleneck no matter where it was handled.

So, I don't see anything here that really breaks the paradigm of the URN
framework acting as a "glue" that ties togethe multiple namespaces. It
is a _good_ case of things to test NAPTR against -- are there people
involved with defining the UUID and IOR namespaces that are interested in
taking on the mapping from those spaces into a URN representation?  This
could be a great test-case for our grandfather-a-namespace issue, if
somebody that represents those namespaces is willing to take it on.

Leslie.

--

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you
                          _are_."                 Bunyip Information Systems
                                                  [phone]
                      -- ThinkingCat              [e-mail]
----------------------------------------------------------------------------